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Abstract 


A  software  product  line  organization  exists  to  produce  products.  Much  of  the  research  on 
creating  products  via  product  lines  has  focused  on  developing  core  assets  such  as 
requirements,  architectures,  and  components.  This  technical  note  presents  the  results  of  a 
study  that  focused  on  how  product  line  organizations  create  products  (e.g.,  their  production 
strategy  and  how  core  assets  are  used  in  the  production  process).  These  results  include 
compiled  responses  to  the  questionnaire  used  in  the  study  and  follow-up  interviews. 
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1  Introduction 


The  ultimate  goal  of  a  product  line  organization  is  to  create  products  efficiently.  Much 
thought  and  effort  goes  into  the  product  line  architecture  and  other  members  of  the  core  asset 
base.  Just  as  much  attention  should  be  focused  on  how  an  individual  product  will  be  specified 
and  constructed. 

Product  line  organizations  have  reported  using  a  number  of  techniques  for  producing 
products.  Griss  reports  on  the  use  of  aspect-oriented  techniques  for  representing  and 
composing  crosscutting  features  in  the  creation  of  a  product  line  [Griss  00].  Batory,  Cardone, 
and  Smaragdakis  report  on  the  use  of  object-oriented  frameworks  and  program  generators  to 
produce  products  in  a  product  line  [Batory  00].  These  papers  focus  more  on  the  individual 
production  techniques  and  less  on  the  overall  production  of  products. 

While  many  of  the  goals  for  a  product  line  can  be  achieved  primarily  through  the  use  of  core 
assets,  certain  goals — such  as  decreased  time  to  market — are  affected  significantly  by 
product  production  techniques.  Given  the  core  asset  base,  the  tools  and  techniques  used  to 
define  and  assemble  a  specific  product  can  significantly  impact  the  efficiency  and  cost  of  the 
product  line  development  effort. 

This  technical  note  reports  on  an  investigation  of  actual  experience  in  product  production. 

The  responses  to  a  questionnaire  and  follow-up  interviews  are  discussed  and  analyzed. 

The  remainder  of  this  report  is  organized  as  follows.  Section  1 . 1  presents  the  concepts 
concerning  product  production  and  production  plans.  Section  2  provides  some  background 
information  on  the  goals  and  expectations  for  the  study,  and  a  digest  of  the  responses  to  the 
questionnaire.  Section  3  analyses  questionnaire  responses  and  highlights  findings  from 
targeted  follow-up  interviews  that  were  prompted  by  those  responses.  Section  4  discusses 
conclusions  and  future  directions  for  product  production  work,  some  of  which  are  currently 
being  investigated. 


1.1  Product  Production 

A  software  product  line  is  a  set  of  software-intensive  systems  sharing  a  common,  managed 
set  of  features  that  satisfy  the  specific  needs  of  a  particular  market  or  mission  and  that  are 
developed  from  a  common  set  of  core  assets  in  a  prescribed  way  [Clements  02] .  A  product 
line  is  sometimes  referred  to  as  a  product  family.  The  core  asset  developers  create  and 
maintain  the  product  line  core  assets,  such  as  the  business  case,  requirements,  software 
architecture,  test  cases,  and  so  on.  The  product  developers  use  the  core  assets  to  develop  the 
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specific  products  in  the  product  line.  The  production  plan1  tells  product  developers  how  those 
core  assets  are  applied  to  build  a  specific  product. 

The  production  plan  evolves  from  the  production  strategy.  That  strategy  begins  as  an 
informal  notion  in  the  business  case,  evolves  concurrently  with  the  core  assets,  and  is 
ultimately  documented  in  the  production  plan.  The  production  strategy  is  based  on  the 
business  goals  of  the  product  line  and  specifies  the  techniques  and  conditions  for  product 
development  that  support  those  goals. 

The  production  strategy  is  realized  in  the  core  assets,  their  attached  processes,  and  the 
production  plan.  The  production  plan  coordinates  the  efforts  of  managers,  product 
developers,  testers,  and  clients.  It  links  together  the  information  provided  by  the  product 
requirements,  business  case,  architecture  description,  component  specifications,  asset-use 
processes,  tool  support,  and  other  sources  such  as  user  manuals.  The  production  plan  expands 
on  the  Technical  Considerations  chapter  of  the  Concept  of  Operations  (CONOPS)2  by 
providing  a  more  complete  description  of  the  process  by  which  products  are  created  [Cohen 
99], 

The  production  plan  provides  an  operational  definition  of  how  the  organization  intends  to 
produce  products.  The  production  plan  for  a  product  line  covers  a  wider  range  of  topics  and  is 
more  complex  than  the  typical  project  plan  used  by  single -product  projects.  While  the  exact 
form  and  content  of  the  production  plan  varies  from  one  product  line  organization  to  another, 
the  plan  is  nonetheless  a  means  of  communication  between  the  core  asset  developers  and  the 
product  developers,  as  well  as  a  source  for  resource  and  schedule  estimates.  The  plan  defines 
the 


•  inputs  needed  to  build  a  product 

•  activities  that  result  in  a  completed  product 

•  roles  and  responsibilities  of  the  product  developers 

•  interactions  needed  with  other  groups  in  the  organization 

•  schedule  and  resources  (including  tool  support)  associated  with  building  the  product 


1  Sometimes  referred  to  as  a  reuser ’s  guide 

2  The  CONOPS  document  is  often  used  to  describe  how  a  computer  system  will  be  managed  and 
operated.  In  product  line  organizations,  the  CONOPS  describes  how  the  organization  operates  and 
helps  personnel  understand  their  roles  and  responsibilities. 
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2  The  Study 


2.1  Purpose 

The  primary  goal  of  the  study  was  to  document  the  state  of  the  practice  in  product  production 
in  software  product  line  organizations.  In  addition,  we  wished  to  provide  concrete  evidence  to 
support  the  observations  in  our  previous  work  about  product  production  [Chastek  02a].  We 
collected  data  from  industry  and  government  product  line  organizations.  Specifically,  we 
invited  the  attendees  of  the  first  and  second  Software  Product  Line  Conferences  [Donohoe 
00,  Chastek  02b]  to  complete  a  questionnaire  about  various  aspects  of  product  production 
[SEI  03].  The  questions  were  based  on  the  production  planning  work  done  by  Chastek  and 
McGregor  [Chastek  02a].  The  ideas  contained  in  that  report  have  been  validated  through 
actual  use  at  one  of  the  Carnegie  Mellon®  Software  Engineering  Institute’s  (SEI’s)  major 
customer  sites. 


2.2  Digest  of  Questionnaire  Results 

We  received  22  individual  responses.  Since  not  all  respondents  answered  every  question,  the 
number  of  responses  for  some  questions  is  less  than  the  total  number  of  questionnaire 
respondents.  Conversely,  the  number  of  responses  to  questions  that  allow  multiple  answers  is 
sometimes  greater  than  the  total  number  of  respondents. 

The  organization  of  this  section  reflects  the  semantic  grouping  of  questions  from  the 
questionnaire.  Each  subsection  includes  the  question  as  it  appeared  in  the  questionnaire, 
followed  by  a  brief  discussion  of  the  responses  to  it. 


2.2.1  General  Information 

How  many  years  has  your  company  been  using  a  product  line  strategy? 

The  responses  ranged  from  0  to  20  years,  with  an  average  experience  of  just  over  5  years. 

What  is  the  domain  in  which  your  product  line(s)  produce  products  (e.g., 
telecommunications,  ground  satellite  support)? 


Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon 
University. 
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A  variety  of  domains  were  reported,  including 

•  military:  ground-based  air  defense  and  air  mission  planning.  Army  training  (specifically, 
instrumented  live  training),  Army  command  and  control,  and  military  command  and 
control 

•  medical:  implantable  medical  devices,  medical  imaging  equipment,  medical  information 
technology,  medical  imaging,  and  medical  systems 

•  automotive:  embedded  power-train  control,  engine  controls,  and  driver  information 
systems 

•  training:  life  and  live  training 

•  electronics:  semiconductors,  consumer  electronics,  and  sensor  systems 

•  miscellaneous:  electric  and  gas  utilities;  information  management,  air  traffic  control,  and 
handheld  communication  devices;  telecommunications;  insurance;  automated  software 
engineering  tools 

Is  that  domain  mature  ?  In  other  words,  are  the  product  features  relatively  stable  or  are  they 
rapidly  changing  with  each  new  product? 

The  majority  of  the  respondents  rated  their  domain  as  relatively  stable,  but  five  rated  their 
domain  as  highly  changeable. 

Is  product  production  automatic  (products  are  generated  with  minimal  product  developer 
effort),  semi-automatic  (products  are  mostly  generated  with  minimal  customization  by  the 
product  developer),  or  largely  manual  (little  of  the  product  is  generated )? 

The  majority  of  the  respondents  described  their  product  production  as  semi-automatic,  while 
two  described  it  as  automatic  and  five  as  largely  manual. 

Does  your  organization  provide  documentation  specifically  for  the  product  developer?  What 
types  of  information  are  supplied  to  the  product  developer?  What  is  the  form  and  structure  of 
that  information? 

While  3  of  the  respondents  stated  that  no  documentation  is  supplied  to  the  product 
developers,  16  of  the  respondents  do  supply  documentation.  The  forms  of  that  documentation 
included 

•  product  management  plans 

•  software  architectures 

•  business  processes,  strategies,  and  procedures 

•  technical  standards 
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•  a  bill  of  materials  of  the  core  assets 


•  user  guides  for  the  core  assets 

Has  your  software  process  been  benchmarked  against  any  standard  such  as  ISO  9000  or  the 
CMM/CMMI?  If  so,  what  was  the  result? 

Eleven  of  the  respondents’  organizations  have  been  benchmarked  against  the  Capability 
Maturity  Model  (CMM)  or  CMM  Integration  (CMMI),  nine  against  ISO  9000,  and  one 
against  the  Electronic  Industries  Alliance  (EIA).  Five  respondents  have  not  benchmarked 
their  software  process,  while  one  did  not  know  if  his  process  had  been  benchmarked. 


2.2.2  Product  Development  Information 

When  do  you  begin  defining  how  products  will  be  built  in  the  product  line? 

In  our  view  of  successful  product  line  development,  product  definition  begins  very  early  in 
the  product  line  life  cycle,  primarily  during  scoping  and  business  case  development.  A  third 
of  the  respondents  indicated  that  they  began  product  definition  during  business  case 
development,  and  one  respondent  defined  products  during  requirements  definition.  However, 
the  majority  began  defining  the  products  in  their  software  product  line  during  software 
architecture  definition. 

What  do  you  consider  to  be  core  assets? 

In  our  view,  development  artifacts — including  software  architecture,  test  cases, 
documentation,  and  processes — are  core  assets.  All  but  one  respondent  considered  the 
software  architecture  and  code  to  be  core  assets.  Most  respondents  considered  requirements 
and  tests  cases  as  core  assets.  However,  only  three  considered  documentation  as  such,  and 
only  two  considered  their  process  as  a  core  asset. 

Are  those  core  assets  described  in  your  production  plan? 

Ten  of  the  respondents  documented  their  core  assets  in  their  production  plan,  while  eight  did 
not. 

Are  the  core  asset  developers  and  the  product  developers  in  distinct  groups,  or  do  the  same 
developers  create  and  maintain  both  the  core  assets  and  the  products?  If  they  are  in  distinct 
groups,  please  describe  the  problems  that  have  arisen  due  to  a  lack  of  communication 
between  the  core  asset  developers  and  the  product  developers. 

Eight  respondents  placed  the  core  asset  and  product  developers  in  the  same  group,  10  placed 
them  in  distinct  groups,  and  one  reported  a  hybrid  grouping. 
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What  information  is  included  in  the  production  plan? 


The  production  plans  of  12  respondents  included  a  schedule  template,  10  included  an 
assembly  process,  and  8  included  a  product  cost  determination  algorithm.  Other  production 
plan  contents  included  the  product  approach,  management  approach,  technical  services  and 
organization,  a  process  for  estimating  time  and  effort,  and  a  quality  procedure. 

How  is  your  production  plan  made  available  to  the  product  developers? 

While  1 1  respondents  indicated  that  they  made  their  production  plan  available  to  product 
developers  using  an  Intranet  Web  page,  12  used  paper  documents.  Other  approaches  used 
included  shared  directories,  presentations,  a  local  network,  BigLever  Software’s  GEARS 
tool,  and  tools  such  as  Microsoft  Excel,  Microsoft  Project,  and  Lotus  Notes  databases. 

How  is  the  production  plan  maintained?  How  do  you  deed  with  the  product  line  evolution, 
particularly  as  it  affects  the  production  plan? 

Four  of  the  respondents  specifically  mentioned  the  use  of  configuration  management  to 
control  the  production  plan.  Many  of  the  respondents  described  maintenance  of  the 
production  plan  as  a  part  of  an  ongoing  iterative  process,  while  several  indicated  that  this  area 
needs  improvement. 


2.2.3  Context 

Does  your  organization  provide  product  line  context  information  to  the  product  developer?  If 
so  then  what  types  of  information  are  supplied,  and  how  are  they  supplied? 

Thirteen  of  the  responding  organizations  indicated  they  provide  some  form  of  product  line 
context  information  (e.g.,  product  line  vision,  strategy,  initial  scope,  expected  benefits)  to  the 
product  developers,  while  three  do  not.  Some  provided  context  information  that  described  the 
position  of  the  product  line  in  the  domain.  Others  provided  context  information  that  described 
the  rationale  and  strategy  for  the  product  line. 


2.2.4  Strategic  View 

What  is  the  product  production  strategy  of  your  current  product  line? 

One  of  our  hypotheses  was  that  product  line  organizations  would  automate  product 
production  where  it  makes  sense  in  view  of  the  organizational  goals  and  capabilities.  All  the 
respondents  listed  more  than  one  production  strategy.  Half  of  them  used  program  generators 
to  build  products,  while  the  other  half  used  some  form  of  software  templates.  All  the 
respondents  also  used  basic  integration  and  development  techniques. 
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How  is  that  strategy  communicated  to  the  product  developer? 


The  two  most  frequent  methods  of  dissemination  were  training  and  documentation.  Three  of 
the  respondents  noted  that  the  strategy  was  communicated  in  the  product  or  production  plan. 

Do  the  product  developers  have  the  same  qualifications  and  background  as  the  core  asset 
developers?  What  are  their  job  titles? 

Fifteen  of  the  respondents  indicated  that  the  personnel  doing  core  asset  development  had  the 
same  qualifications  as  those  doing  product  development.  The  respondents  who  acknowledged 
differences  between  the  groups  indicated  that  they  were  mainly  depth  of  education  and 
breadth  of  vision. 

When  is  the  software  integrated  with  hardware?  When  the  product  is  delivered? 

With  two  exceptions,  respondents  viewed  integration  as  an  iterative,  ongoing  activity 
regardless  of  whether  special-purpose  hardware  was  involved.  Little  or  no  difference  was 
identified  for  a  product  line  organization.  One  respondent  felt  that  this  was  too  simplistic  a 
question.  Their  products  contain  a  variety  of  hardware  and  software,  and  integration  occurs  at 
a  number  of  times  and  places.  (Those  products  operate  in  a  distributed  environment  and  must 
be  tested  for  such  an  environment.) 

When  are  variations  resolved  in  your  product  line? 

Product  line  organizations  resolve  variation  at  many  points.  Respondents  were  given  a  choice 
of  design,  compile,  install,  or  run  times.  The  vast  majority,  20  and  19  respondents 
respectively,  resolved  variation  at  design  time  and  compile  time.  Eleven  of  those  respondents 
resolved  variation  at  all  four  points. 

Where  does  most  of  the  binding  of  variation  points  occur? 

Product  line  organizations  use  a  wide  variety  of  binding  times.  Two  respondents  indicated 
that  this  was  a  difficult  question  to  answer  because  of  the  many  places  where  binding  occurs. 
Another  respondent  indicated  that  load  time  and  various  levels  of  installation  time  were 
omitted  from  the  survey.  Interestingly,  four  respondents  bind  only  at  compile  time. 

What  effect,  if  any,  have  you  seen  on  the  production  strategy/plan  as  a  result  of  handling 
variation  at  these  points  in  the  product  development  flow? 

One  respondent  wrote,  “Management  of  variation  is  probably  the  most  significant  factor  in 
the  design  of  the  production  strategy/plan.”  Four  respondents  saw  no  effect  and  one  wasn’t 
sure.  Other  comments  supported  conventional  wisdom: 
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•  “Variations  must  be  well  documented  and  visible  to  the  product  developers  to  avoid 
costly  rework.” 

•  “If  you  haven’t  anticipated  all  the  variability  you  need,  you  pretty  much  can’t  avoid 
going  back  through  domain  engineering  and  correcting  this  there.  Quick-fix  hacks  can 
work  for  a  little  while,  but  are  big  problems  if  they  aren’t  handled  properly  pretty 
quickly.” 

•  “Runtime  configurable  options  have  been  a  major  source  of  improvement  in  time  to 
market  and  stability  and  flexibility  of  the  product.” 

2.2.5  Available  Core  Assets 

How  are  the  core  assets  made  available  to  the  product  developers? 

Twelve  respondents  said  that  core  assets  are  made  physically  available  via  a  searchable 
repository.  Others  reported  less  formal  channels,  including  a  catalog,  a  course  or  tutorial, 
asset  experience  gained  on  previous  projects,  and  word  of  mouth. 

Describe  any  other  information  that  the  core  asset  developers  currently  provide  to  product 
developers  to  help  them  build  products.  How  has  that  information  changed  as  the  product 
line  has  matured? 

Respondents  listed  different  types  of  information  that  are  provided  about  the  core  assets, 
including  information  about  the  range  of  variations  possible  in  a  specific  asset  and  guidance 
on  tuning  a  product.  Other  information  is  provided  to  the  product  developers  by  the  core  asset 
developers  in  the  form  of  peer  reviews  and  working  groups;  guidelines  and  coding  standards; 
initiatives  involving  the  business-object  modeling  of  requirements  using  the  Unified 
Modeling  Language  (UML)  and  automated  analysis  of  models;  specifications  and  design; 
workshops;  and  problem  report  and  change  request  databases. 


2.2.6  Detailed  Product  Production  Process 

Is  there  a  formal  product  production  process  definition  ? 

The  respondents  were  evenly  split  on  whether  they  have  a  formal  production  planning 
process.  Four  respondents  felt  they  had  some  process,  but  a  less  mature  one  than  needed. 
Several  consider  their  production  process  to  be  proprietary  and  so  were  unable  to  disclose 
any  details  without  a  nondisclosure  agreement. 

How  does  the  product  production  process  relate  to  the  organization ’s  overall  software 
development  process? 
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Three  respondents  saw  no  difference  between  the  two  processes.  Four  respondents  saw  the 
product  production  process  as  a  subprocess  of  the  software  development  process.  Three  saw 
the  two  processes  as  related  but  separate  from  each  other. 


2.2.7  Management  Information 

What  metrics  have  proven  successful  in  quantifying  the  production  process? 

Several  respondents  have  no  metrics  for  quantifying  their  product  production  process.  The 
others  listed  various  metrics,  some  of  which  were  identical  to  those  commonly  used  in 
software  development  efforts.  These  metrics  included 

•  source  lines  of  code  (SLOC) 

•  cost 

•  productivity 

•  quality  (errors  and  defects) 

•  effort 

•  open  and  resolved  problem  reports 

•  effectiveness  curve  for  new  engineers 

•  change  request  metrics 

Other  identified  metrics  are  unique  to  a  software  product  line  development  effort,  including 

•  number  of  products  created 

•  levels  of  reuse 

•  ratio  of  variability  to  commonality  (in  code  and  requirements) 

•  function  points  for  core  assets 

•  time  to  market  per  product 

•  number  of  products  produced  per  month 

Have  the  initial  expectations  of  the  product  line  been  met? 

The  majority  of  respondents  (13)  felt  that  the  product  line  approach  had  largely  or  completely 
met  their  expectations.  Six  respondents  either  had  set  no  specific  expectations  or  had  not  yet 
evaluated  whether  their  expectations  had  been  met.  Only  three  felt  their  expectations  had  not 
been  met. 
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Has  the  production  of  products  been  as  efficient  and  inexpensive  as  initially  expected? 


Most  respondents  felt  it  was  too  soon  in  their  use  of  the  product  line  approach  to  say  much 
about  benefits.  One  respondent  said  that  the  assets  took  longer  to  develop  and  cost  more  than 
expected.  Another  respondent  indicated  that  the  efficiency  and  cost  of  his/her  product  lines 
varied  and  that  some  product  lines  did  not  result  in  profit.  One  respondent  believed  that 
his/her  company  could  reduce  the  number  of  assets  needed  to  create  a  product,  but  because 
the  appropriate  managers  were  not  yet  convinced,  the  company  was  not  benefiting  from  the 
product  line  approach. 
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3  Results 


We  report  on  two  kinds  of  results  below: 

1 .  the  direct  results  obtained  from  examining  the  questionnaire  responses.  These  results  are 
reported  in  terms  of  the  correlation  between  product  line  success  and  specific 
characteristics  of  the  reporting  organization  (e.g.,  domain  experience). 

2.  additional  findings  arising  from  follow-up  interviews  with  specific  respondents 

3.1  Preliminary  Analysis  of  Responses 

In  this  section,  we  consider  relationships  among  certain  aspects  of  product  production.  Using 
the  questionnaire  responses  reported  in  Section  2.2,  we  explored  relationships  between  the 
answers  to  one  question  and  those  for  another.  Due  to  the  small  sample  size,  we  used  chi- 
square  contingency  tables.  The  “Expected”  dimension  of  the  table  was  based  on  a 
hypothesized  relationship  between  the  concepts  measured  by  two  questions.  The  actual 
questionnaire  responses  made  up  the  “Actual”  dimension  of  the  table.  In  the  descriptions 
below,  we  indicate  which  of  those  comparisons  indicated  a  statistically  significant  result.  For 
those  comparisons,  we  include  the  level  of  confidence  in  that  relationship. 

As  mentioned  in  the  previous  section,  a  majority  of  the  questionnaire  respondents  felt  that  the 
product  line  approach  had  largely  or  completely  met  their  expectations.  An  analysis  of  the 
responses  indicated  that  there  is  a  positive  correlation  between  a  product  line’s  being  reported 
as  having  met  expectations  and  several  other  responses,  including 

•  experience  in  the  domain:  There  was  a  positive  correlation,  but  the  relationship  did  not 
reach  statistical  significance.  This  does  (weakly)  support  the  common  notion  that  domain 
issues  (e.g.,  experience  in,  leadership  in,  and  stability  of  the  domain)  play  a  major  role  in 
product  line  practice.  Additional  analysis  shows  a  statistically  significant  relationship 
between  a  product  line  having  met  expectations  and  the  stability  of  the  domain  within 
which  the  product  line  resides. 

•  use  of  separate  core  asset  and  product  development  teams:  The  relationship  between 
meeting  expectations  and  having  separate  teams  for  core  asset  development  and  product 
production  was  significant  at  the  .001  level.  This  result  seems  to  indicate  that  the  two 
roles  are  difficult  to  manage  in  a  single  team. 

•  whether  the  two  groups  have  the  same  qualifications:  This  relationship  between  meeting 
expectations  and  members  of  core  asset  and  product  teams  having  the  same  qualifications 
was  statistically  significant  at  the  .001  level.  It  may  indicate  that  having  highly  qualified 
staff  in  both  roles  aids  in  meeting  expectations. 
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•  when  product  definition  begins:  Dividing  the  answers  into  two  categories — early  and 
late — created  a  statistically  significant  relationship  at  the  .01  level  between  beginning 
product  definition  early  and  having  the  product  line  meet  expectations. 


3.2  Additional  Findings 

The  analysis  of  the  questionnaire  responses  raised  several  questions.  Since  several 
respondents  to  the  questionnaire  had  indicated  a  willingness  to  be  contacted,  we  asked  a  few 
of  them  additional  questions.  Their  responses  may  not  be  representative  of  the  group  as  a 
whole  and  are  offered  as  descriptive  information  only. 


3.2.1  Product  Production 

The  interviews  confirmed,  through  the  experience  of  the  respondents,  certain  basic  notions. 

•  Core  assets  cost  approximately  50%  more  effort  to  produce  than  non-reusable  assets. 

•  Even  an  organization  that  was  achieving  70-80%  reuse  can  expect  to  increase  that 
amount  using  the  product  line  approach. 

•  Time-to-market  goals  continue  to  be  achieved.  One  respondent  built  one  product  in  one 
year  and  then  seven  products  in  the  first  six  months  of  the  next  year. 

3.2.2  Hierarchical  Product  Line  Definitions 

The  interviews  brought  up  the  issue  of  relationships  among  product  lines  and  the  concept  of  a 
subproduct  line.  Some  of  the  respondents  used  a  commonality  and  variability  approach  to 
define  the  differences  between  products  within  a  product  line.  Two  respondents  used  the 
concept  of  subproduct  lines  where  the  differences  among  sets  of  products  outweighed  the 
commonality.  As  shown  in  Figure  1 ,  a  certain  amount  of  asset  reuse  occurs  across  the  entire 
product  line.  However,  the  degree  of  reuse,  as  indicated  by  the  thickness  of  the  arrow,  is 
much  higher  among  products  within  the  same  subproduct  line. 

Following  up  on  responses  to  the  questions  about  variations  and  production  strategy,  we 
identified  two  different  approaches  being  used  to  identify  and  design  products: 

1 .  Perform  a  commonality  and  variability  analysis  of  the  domain  or  domains.  In  this 
approach,  the  choices  possible  at  a  variation  point  indicate  possible  different  products. 
All  possible  combinations  of  choices  at  all  variation  points  define  all  possible  products. 
The  organization  then  selects  certain  combinations  to  build  as  products. 

2.  Construct  product  requirements  for  a  desired  set  of  products.  These  requirements  are 
grouped  into  various  subsets  based  on  shared  requirements.  Sets  of  products  that  share  a 
large  number  of  these  subsets  are  viewed  as  a  subproduct  line  within  the  overall  product 
line. 
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The  choice  of  approach  seems  to  be  related  to  the  breadth  of  vision  of  the  organizational  unit 
defining  the  product  line.  If  the  unit  is  at.  or  near,  the  top  of  the  organization,  the  breadth  of 
products  is  likely  to  be  similar  to  the  outer  oval  in  Figure  1.  If  the  unit  is  a  “product  group” 
within  a  larger  organization,  the  view  is  probably  restricted  to  one  of  the  internal  ovals.  In  a 
sense,  one  level  of  scoping3  has  already  been  done  by  the  organization. 


Figure  1:  Subproduct  Lines  Within  a  Product  Line 

3.2.3  Production  Planning 

One  of  the  follow-up  interviews  reinforced  the  necessity  of  early  production  planning.  This 
respondent,  a  veteran  of  two  product  lines,  had  learned  from  experience  the  problems  that  can 
arise  if  production  planning  is  put  off. 


3.2.4  Production  Process 

An  interesting  hybrid  approach  to  creating  a  production  process  was  elicited  during  the 
interviews.  In  this  approach,  an  infrastructure  is  created  up  front  that  provides  commonality 
among  all  the  subproduct  lines.  When  the  first  product  in  the  subproduct  line  is  constructed, 
the  infrastructure  is  used  to  define  a  production  process  for  the  products  within  that  group. 


3  Scoping  is  the  activity  that  bounds  the  product  line  by  defining  what’s  “in”  and  what’s  “out.”  The 
goal  of  scoping  is  to  define  this  boundary  so  the  chosen  set  of  products  will  be  profitable.  For  more 
information,  see  the  Scoping  practice  area  of  A  Framework  for  Software  Product  Line  Practice 
[Clements  04], 
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This  approach  implicitly  assumes  that  products  within  the  subproduct  line  share  common 
characteristics  such  as  variation  resolution  and  binding  times. 
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4  Conclusions  and  Future  Directions 


The  data  collected  in  this  research  helped  us  to  achieve  the  goals  of  the  study.  The  diversity 
of  the  domains  and  the  range  of  the  respondents’  experience  levels  ensure  that  the  responses 
on  the  questionnaire  are  representative  of  software  product  line  organizations.  In  addition,  the 
data  enabled  us  to  validate  several  of  the  relationships  described  in  our  previous  work.  And, 
of  course,  we  identified  some  remaining  challenges  that  are  described  below. 

The  responses  yielded  several  interesting  results.  In  particular,  the  data  illustrated  the 
diversity  of  approaches  being  followed  in  product  line  organizations  with  regard  to 
production  planning.  As  discussed  in  the  previous  section,  we  analyzed  some  aspects  of  those 
approaches  and  identified  certain  relationships  among  them.  These  results  identified  certain 
practices  as  successful  with  respect  to  a  product  line’s  meeting  its  expectations. 

The  data  also  illuminated  some  areas  that  require  further  investigation.  Our  future  research 
will  attempt  to  develop  or  identify  successful  practices  in  these  areas.  Some  of  the  issues  to 
be  addressed,  in  so  far  as  they  provide  insight  into  product  production,  are  the  following: 

•  There  is  no  standard  vocabulary  for  discussing  product  production  in  a  software  product 
line.  The  wide  range  of  responses  to  some  questions  led  us  to  provide  more  complete 
definitions  and  to  expect  more  diversity  in  the  answers.  Our  future  research  will  include  a 
domain  model  of  product  production  to  which  various  approaches  and  terminology  can 
be  mapped. 

•  Product  line  organizations  use  a  wide  range  of  variation  resolution  and  definition  binding 
times,  often  within  a  single  product  line.  Our  future  research  will  attempt  to  more 
completely  capture  and  analyze  the  range  and  the  flexibility  that  variability  and  binding 
decisions  bring  to  product  production. 

The  results  of  the  study  also  highlighted  areas  in  which  further  research  by  the  product  lines 
community  would  be  useful: 

•  The  management  and  evolution  of  the  production  plan  is  not  well  understood.  This  is  part 
of  the  larger  concern  about  evolution,  which  we  have  previously  addressed  [McGregor 
03], 

•  The  relationship  between  the  software  development  process  and  the  product  production 
process  is  complex  and  not  well  understood.  There  is  a  need  for  research  into  the 
appropriate  processes  and  relationships  among  these  processes.  This  research  would 
investigate  how  to  differentiate  between  component  development  processes  and 
component  integration  processes. 
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